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ABSTRACT 


The author presents a new framework for evaluating the evolutionary upgrade paths 
of command, control, and communications systems. C°* system procurements today can 
be viewed as upgrades to existing C’ systems. Most operational C* functions are 
performed today by commanders and their staffs with various levels of automated 
support. The upgrade procurements are intended to increase or improve this automated 
support. The author examines the shrinking budget, technology initiatives, Evolutionary 
Acquisition, Commercial-Off-The-Shelf (COTS), Non-Developmental-Items (NDI), and 
emerging open architecture standards. Current evaluation frameworks, the Mission- 
Oriented Approach (MOA), the Modular Command and Control Evaluation Structure 
(MCES), and a Cost and Operational Effectiveness Anaylsis (COEA), are examined. An 
illustration oF the framework uses the United States Marine Corps’ Tactical Combat 
Operations (TCO) System. Conclusions stress that C* systems can be viewed as 
evolutionary upgrade paths that change over time, that effective evaluations of 
evolutionary C* systems must consider the temporal component, and that a framework, 
such as the one presented in this thesis, is needed for comparing alternative upgrade 


paths rather than alternative static C°* systems. 
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I. INTRODUCTION 


A. PURPOSE OF THESIS 

The purpose of this thesis is to present a new framework for evaluating alternative 
evolutionary upgrade paths for command, control, and communications systems. 
Unprecedented changes in the international strategic environment, coupled with 
increasing domestic budgetary pressures, necessitated a shift in US defense strategy and 
are reflected in the new national military strategy published in January 1992. The new 
strategy shifts its focus from containing communism and deterring Soviet aggression to 
a more flexible, regionally oriented strategy capable of countering a wide range of 
potential threats to vital US interests. [Ref. 1:p. -1] Guidance on changing C* systems 
and objectives have lead to initiatives such as C*I for Warrior, the Navy’s Copernicus 
concept, and the Navy and Marine Corp’s "...From the Sea" strategy. Specifically, in 
the area of acquisitions, the use of an evolutionary type acquisition concept for the 
acquisition of new C* systems is now mandated by DoD [Ref. 2:p. 5-A-5]. 

Most C?* systems that are procured today and in the future will undoubtedly 
incorporate incremental evolutionary upgrades during their useful life cycle. The author 
proposes a methodology for evaluating alternative C’ systems that considers this temporal 


component by evaluating incremental upgrade paths. 


B. METHODOLOGY 

In order to understand the problems associated with evaluating C’ systems, the 
major issues that effect C’ system evaluation will be discussed. Then, the merits of some 
the current evaluation frameworks will be examined followed by the introduction of the 
new framework. To clarify the concepts introduced by the new framework, an illustrated 
example is presented using the United States Marine Corp’s Tactical Combat Operations 
(TCO) system. 

A major issue the new framework will address is the difficult, but ever present, 
temporal component of C*® systems. The author proposes that effective evaluations of 
new C° systems must include an evaluation of its planned upgrade path toward some goal 


or target level of functionality. 


C. SCOPE OF THESIS 

The main focus of this thesis is to present a useful framework for evaluating 
evolutionary upgrade paths of C*® systems. Only a general discussion of the important 
issues that effect evaluations will be given to characterize the evolutionary environment. 
The thesis will only address those issues that effect generic C’ systems. After the 
framework is presented, an illustration will be presented using the TCO alternative 
systems established by the Marine Corps about the time of this writing. All values and 
costs used in the illustration are chosen for illustrative purposes only due to the 


unavailability of actual values. 


In order to maintain a smooth flow between the discussion of the framework in 
Chapter III and the illustration in Chapter IV, the background and history of TCO and 
the Marine Tactical Command and Control System (MTACCS) will be presented in 


Section D of this chapter. 


D. DEFINITION 

The official Department of Defense (DoD) definition for a command, control, and 
communications system is: 

The facilities, equipment, communications, procedures, and personnel essential to 
a commander for planning, directing, and controlling operations of assigned forces 
pursuant to the missions assigned. 

A command, control, and communications (C°*) system is a collection of tools the 
decision maker uses. It is a collection of facilities, equipment, communications, 
procedures, and personnel that helps the decision maker gather, process, and disseminate 
information. [Ref. 3:p. 1] With the increasing reliance on computer systems, the term 
command, control, communication, and computers (C’) is also widely used. Likewise, 
C*I and C’I’ have been popular terms that highlight the contributions of intelligence and 
interoperability. 

To avoid confusion, the author will strictly use the term C* system. C°* systems can 
also be viewed as a collection of tools that provide automated support to those functions 
that commanders have always performed (e.g., planning, directing and controlling his 
forces). Most operational Command, Control, and Communications (C’) functions are 


done today, but the level of automation of each function varies from system to system. 


Upgrades to C* systems will either fully automate a C? function or provide automated 
support to the function. In either case, it will be referred to as automating the function.’ 


Some C? functions may even stay manual. 


E. BACKGROUND AND HISTORY OF MTACCS AND TCO 

The Marine Tactical Command and Control System (MTACCS) is the Marine 
Corp’s current command and control concept and is compliant with the goals of C’*I for 
the Warrior. It stresses the integration of separate automation assisted Marine Air 
Ground Task Force (MAGTF) C? systems which support tactical operations. MTACCS 
enhances the commander’s decision making capability and provides tools necessary for 


effective and efficient C? on the battlefield. 
1. Background and History of MTACCS 


a. The Need 

The National Security Act of 1947 requires that the Marine Corps 
provide rapidly deployable amphibious forces for contingency missions in support of the 
national strategy. A key statutory mission of the Marine Corps is to provide MAGTFs 
for service with the fleet in the seizure or defense of advanced naval bases and for the 
conduct of such land operations as may be essential to the prosecution of a naval 
campaign. The coordination of such a large number of forces and equipment deployed 
over a wide geographic area demonstrates the requirement for an automated C* system 


to effectively manage the assets available. [Ref. 4:p. 1] 


' These aspects will be expanded upon in Chapter III. 


An automated C® system that can be used in peace as well as combat 
would facilitate the prosecution of battle and make more effective use of available 


resources. 


b. Historical Summary 

The MTACCS concept started with C’ studies conducted during 1965 and 
1966, which resulted in the Marine Corps General Operational Requirements (GOR) No. 
CC-9, Marine Corps Tactical Command and Control Systems (MTACCS), issued in 
1967. The USMC issued the first MTACCS Master Plan in 1976 to provide policy and 
guidance for the integrated management of efforts to improve tactical C’. The last update 
of that plan was in 1981. Beginning in 1983, Headquarters Marine Corps (HQMC) 
incorporated the MTACCS Master Plan into the Marine Corps Command and Control 
Master Plan (C’MP), last revised in August of 1987. Termination of the Marine 
Integrated Fire and Air Support System (MIFASS), a cornerstone of MTACCS in the 
original a caused the MTACCS philosophy to enter a two year period of 
dormancy. Only nominal integration of tactical data systems occurred during that period. 
The current MTACCS program will revitalize the original concept, update it to reflect 
the current needs of the MAGTF, and bring a modern tactical C’ system to fruition. 
[Ref. 5:pp. 1-3] 

The objective of the MTACCS concept is to provide MAGTF 
commanders with an integrated set of systems which can receive, process, display, store, 
and distribute essential information. Figure 1 portrays the MTACCS concept as it is 


currently envisioned. 
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Figure 1: Marine Tactical Command and Control System 





2. Background and History of TCO 


a. Background 
Marine tactical commanders face unprecedented challenges in exercising 
C’ on the modern battlefield. The tempo of operations has increased, the MAGTF 


commander’s area of interest has expanded, and more data is required to support tactical 


decision making. The ability to gather, process, and disseminate tactical information is 
critical to the operational success of the MAGTF. The Marine Corps has long- 
recognized the need for an automated system to improve these C’ capabilities and first 
identified this requirement as General Operational Requirement Number CC-9 of 28 July 
1967. The requirement for the TCO system is documented in MNS, No. CCC 1.31A, 
approved by the Assistant Commandant of the Marine Corps and issued by the 
Commanding General, Marine Corps Combat Development Command (MCCDC), on 16 
June 1992. Technology is now available to support development of a command and 
control system that will significantly enhance the commander’s ability to plan and execute 


MAGTF operations. [Ref. 6:p. 1-1] 


b. Operational Concept 
The new approved standard general description of TCO as it is published 
in Campaign Plan 1- 93 is as follows: 


The Tactical Combat Operations (TCO) system will serve as the operations 
component to the Marine Tactical Command and Control System (MTACCS). 
TCO will use microcomputers to provide commanders the automation to receive, 
fuse, select, and display information from many sources, and disseminate selected 
information throughout the battlefield. TCO attributes include: automated message 
processing, mission planning, development and dissemination of operations orders 
and overlays, display of current friendly and enemy Situations, display of tactical 
control measures, and interfaces with local and wide area networks. [Ref. 7:p. C- 
2-1) 


TCO will be employed at the Command Element of the Marine 
Expeditionary Force (MEF), the Marine Expeditionary Brigade (MEB), and the Marine 
Expeditionary Unit (MEU). All staff sections of the MAGTF command element will 


interface with TCO. The system will support MAGTF commanders and their staffs 


down to the battalion level in the Ground Combat Element, down to the squadron level 
in the Aviation Combat Element, and down to the battalion (and possibly company) level 
in the Combat Service Support Element. The principle users of TCO will be the 
MAGTF commanders and their operations staff. Operators will be watch officers and 
trained enlisted personnel. 

The TCO system is designed to enhance the commander’s ability to focus 
on critical elements of information while making battlefield decisions. It will use state- 
of-the-art technology to provide a mobile, flexible, and reliable system that is able to 
interface with existing Marine Corps, other services, and joint systems. 

TCO will be composed of computerized workstations, connected by the 
designated Marine Corps standard local area networks (LAN) within each command post. 
These workstations will provide a graphical user interface and keyboard and/or pointing 
device; information processing and display; graphics; communications interface; and hard 
copy pantOut. LANs will be interconnected by wide area networks to other 
geographically dispersed command posts (CPs) via tactical communications assets. 
Separate, but reconfigurable, workstations are used for conduct of current operations and 
planning. This redundancy supports continuity of operations during CP displacement. 
[Ref. 6:p. 1-5] 

3. Current Status of TCO 
The Marine Corps Combat Development Command (MCCDC) Studies and 
Analysis Division is currently doing a Cost and Operational Effectiveness Analysis 


(COEA) on the selected TCO alternatives. These alternatives will provide automated 


support for many of the functions presently handled manually in the Combat Operations 
Center. The following paragraphs outline briefly the current alternative systems being 


considered for fulfilling the requirements of TCO. 


a. Base Case 
This alternative would be to continue the status quo. Fleet Marine Force 
(FMF) units are currently using organic tactical communications, microcomputers, and 
the tactical digital facsimile to establish C? networks. These locally developed networks 
partially satisfy FMF requirements for automated support of operations planning and 
execution. Applications include locally developed programs tailored to support the needs 
of individual units as well as programs distributed Marine Corps-wide. However, they 


are unique to a particular MEF. 


b. Maneuver Control System (MCS) 

_ Under this alternative, MCS Version 11 software would be modified to 
ue TCO requirements. MCS is a component of the Army Tactical Command and 
Control System designed to provide support for operations planning and execution. 
Version 10 of MCS 1s currently fielded. Version 10 provides minimum capability and 
imposes a significant logistics burden. Version 11 is being developed by LORAL under 
contract to the U.S. Army Communications-Electronics Command. MCS Version 11 
will collect, store, retrieve, process, and disseminate tactical information. A digital map 


and graphic overlay capability is provided. MCS Version 11 will operate in either a 


standalone or LAN configuration on a common set of computers from the Army Tactical 


Automated Command and Control System Common Hardware and Software program. 
Communications interfaces are provided to the Army tactical communications networks, 
which include single channel radio, mobile subscriber equipment, and the Army Data 


Distribution System (EPLRS/JTIDS). 


c. Command Tactical Information System (CTIS) 

Under this alternative CTIS software would be modified to meet TCO 
requirements. CTIS is a C’ system developed by and fielded within the Alaskan 
Command. CTIS currently operates in an Apple Macintosh environment and is being 
ported to a UNIX-based, open systems environment. CTIS uses commercial and tactical 
phone lines and commercial modems for data communications. CTIS provides the 
battlefield commander a tool for collecting, storing, processing, and displaying 


information. CTIS has a digital mapping and graphic overlay capability. 


d. Intelligence Analysis System (IAS) 

This alternative would satisfy TCO requirements through modification 
of the JAS. IAS is designed to support tactical intelligence collection, processing, and 
dissemination down to battalion level. The IAS is being developed by the Marine Corps 
Tactical Systems Support Activity (MCTSSA) at Camp Pendleton, California. IAS is 
currently hosted on a SPARC 2 server/workstation running a SunOS UNIX operating 
system. IAS supports generation of digital maps and overlays depicting the current 
situation. Information that can be displayed includes tactical control measures, targets, 


standard military symbology, and unit status data. IAS uses Defense Mapping Agency 
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(DMA) map products. Other capabilities include U.S. Message Text Format message 
preparation, ad hoc data base query, and generation of plans and orders. IAS Version 
1.2 is currently fielded and has been used in a Special Operations Command Exercise by 
24 MEU. Version 2.0 is scheduled for release during the second quarter FY 93 and will 


provide a substantial enhancement to IAS communications capabilities. 


e. Combat Information Processor (CIP) 

Under this alternative, the Marine Corps would continue the development 
of CIP to incorporate additional capabilities required for TCO. CIP was developed by 
the Advanced Sensors Systems Branch of the Harry Diamond Laboratories in support 
of the Amphibious Warfare Technology Directorate of Marine Corps Systems Command. 
This development was conducted as an advanced technology demonstration prototype. 
The CIP system is housed in an environmentally controlled Standard Integrated 
Command Post Shelter mounted on a M1037 High Mobility Multipurpose Wheeled 
Vehicle. The system provides situation awareness through a sophisticated digital map 
capability. 

f. Naval Tactical Command System-Afloat (NTCS-A) 

Under this alternative, the Marine Corps would extend NTCS-A to meet 
TCO requirements. NTCS-A is managed by the Space and Naval Warfare Systems 
Command and developed by the Research, Development, Testing and Evaluation 
(RDT&E) Division of the Naval Command, Control, and Ocean Surveillance Center. 


NTCS-A application programs include functional applications, such as the Joint 
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Operations Tactical System and the Naval Intelligence Processing System, incorporated 
into unified builds. NTCS-A relies on shipboard front-end processing and media access 
for local and external communications. NTCS-A can access various communications re- 
sources (AUTODIN, tactical link communications and TTY) through the communications 
server/front-end processor. The NTCS-A provides the Navy tactical commander the 


information necessary to plan and execute operations. 


g. Maestro 

Command Systems Incorporated (CSI) developed the FDS-1 TCO proto- 
type. Since that time, CSI has continued to work on automated C’ systems and is 
currently marketing a product called Maestro. Under this alternative, the Marine Corps 
would acquire the current version of Maestro and modify the software to meet the TCO 
requirements. The current version of Maestro runs on a DOS operating system. 
Maestro would have to be ported to run on the UNIX operating system using an X- 
Windows/Motif GUI. Maestro uses scanned paper maps and overlays to depict the 
current situation. Information that can be displayed includes tactical control measures, 


targets, standard military symbology, and unit status data. [Ref. 8:pp. iv-vi] 


F. OUTLINE OF CHAPTERS 


1. Chapter Il. The Issues 
In this chapter, the important issues of the emerging evolutionary 
procurement environment are discussed. Issues such as current technology initiatives, 


Evolutionary Acquisition, Non-Developmental-Items (NDI), Commercial-Off-The-Shelf 
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(COTS) products, and "open system" standards are presented along with their effect on 
the procurement of C* systems. The Mission-Oriented Approach (MOA), the Modular 
Command and Control Evaluation Structure (MCES), and the Cost and Operational 
Effectiveness Analysis (COEA) team’s evaluation approach are presented to highlight the 


current methodologies and frameworks used to evaluate C* systems. 


2. Chapter DI. A New Framework 
In this chapter, a new framework for evaluating evolutionary upgrade paths 
of C*® system alternatives is presented. The framework is a functionally-oriented, 
capability-based approach that is intended to be a useful step by step method that 
produces valuable information about the upgrade paths of selected alternatives. Each step 
of the framework is presented along with recommended methods and procedures for 


accomplishing each step. 


3. Chapter IV. An Illustrated Application 
In this chapter, an illustration of the framework will be done using the Marine 
Corp’s Tactical Combat Operations (TCO) system. The illustration will clarify how to 
apply the concepts and procedures of the framework. A simple step by step discussion 
of how to perform each step of the framework will be presented using subjective data do 


to the unavailability of actual data. 
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Ii. THE ISSUES 


A. INTRODUCTION 

Several recent initiatives such as DoD’s Corporate Information Management 
initiative and the Joint Chiefs of Staffs "C*I for the Warrior" plan have proposed new 
ways to do business. These initiatives serve to create a procurement environment that 
is business-driven, strategically planned, standards based, integrated, evolutionary, and 
more efficient. C*® systems procured in this environment will utilize Evolutionary 
Acquisition and incorporate Non-Developmental-Items, Commercial-Off-The-Shelf 
products, and "open systems" standards. 

In order to accurately and effectively evaluate current or future C* systems, the 
current and future environment in which they are acquired must be understood. This 
chapter will discuss aspects of C? system procurement today, the current C’ technology 
initiatives, evolutionary acquisition, and open architecture standards. Some current 


evaluation frameworks will then be discussed to highlight the methodologies in use today. 


B. C> SYSTEMS TODAY 

C? system procurements today can be viewed as upgrades to existing C* systems. 
Most operational C* functions are performed today by commanders and their staffs with 
various levels of automated support. The procurements are intended to increase or 


improve this automated support. Even large procurements that make sweeping changes 
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(e.g., new C® systems) will be incremental and evolutionary. Therefore, it is useful to 
explicitly embrace the evolutionary upgrade concept, and develop a framework for 


comparing alternative upgrade paths rather than alternative static C* systems. 


C. TECHNOLOGY INITIATIVES 


1. Current State of Technology 
America is in the midst of a technological revolution that will dramatically 
change the way companies and DoD do business. NCR Chairman and CEO Gilbert 
Williamson has said: 


"...[The one constant of the information technology industry is change-rapid 
change...."? 


This continuing changing nature of technologies will directly effect the C* systems that 
incorporate new technologies. 

New, advanced technologies can permit significant restructuring in the way 
information is acquired, processed, and disseminated. Some functions requiring 
expensive and scarce resources can be centralized and automated to reduce required 
equipment, facilities, and skilled personnel. Reliable, wideband communications can 


enable centralized support to be rapidly provided to deployed forces. [Ref.1:p. III-15] 


* Taken from an article titled "Users Call the Shots, Says NCR CEO in Expo Keynote" in 
PC Week Magazine, 29 June 1992. 
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2. Key Technologies 
In May of 1985, the Assistant Secretary of Defense for C*I tasked the 
Defense Communications Agency’ to undertake a projection and assessment of the 
impact of technology on the future C* systems of the DoD. DISA published the report 
called "Report of C’ Technology Assessment" in January, 1987. The C’ Technology 
Assessment concluded that the DoD should exploit technological opportunities to effect 


profound improvements in future C* system in the following areas: 


1. To make C® systems "smarter"; 
2. To improve software productivity; 
3. To provide for the distribution of C° assets for survivability; and 


4. To cope with security vulnerabilities. 


Above all, it will require further emphasis on systems engineering and 
technology transition; and the use of technology in growing C’ capabilities in place, in 
contrast to building C* turn-key systems. The report highlighted that this will require 


further R&D work in seven major technology categories: 


1. Distributed C* Systems. 
2. Telecommunications Technology. 
3. Command Decision Support Systems. 


4. Information Security. 


> Now called the Defense Information Systems Agency (DISA). 
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5. Software Engineering. 
6. Artificial Intelligence. 


7. Photonics. 


The report stimulated the continuation of the C’ technology assessment effort, 
including the conduct of additional workshops and the initiation of work on protocols and 


standards within the framework of an overall C°* technical architecture. [Ref. 9] 


3. The Effect on C* systems 

Technological research will continually produce advances that will improve 
and streamline the way C* systems perform their mission. New advances will provide 
new capabilities that will enable current C* systems to provide better automated support 
to the C® functions it supports. As new capabilities become available, existing C° 
systems will incrementally add these capabilities by incorporating several upgrades during 
their useful-life cycle. This results in a temporal component that must be dealt with. 

The evolutionary acquisition concept has been recognized as the best way to 
incorporate these new technology based capabilities into existing C’ systems. The 


following section will discuss this concept. 


D. THE EVOLUTIONARY ENVIRONMENT 

It has long been recognized that the standard DoD weapon system acquisition 
process is poorly suited to the acquisition of C* systems. Instead, an evolutionary 
process of "growing" a C*® system-"build a little, test a little"-has recently been 


advocated. [Ref. 10:p. 6] The National Military Strategy Document for FY 94-99, the 
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"C*I for the Warrior" plan, and DoD Instruction 5000.2, "Defense Acquisition 
Management Policy and Procedures", all mandate the use of evolutionary acquisition for 
the procurement of DoD C’ systems. 

In the late 1980’s, General Alfred M. Gray (Commandant of the Marine Corps) put 
Out initiatives to reorganize the Marine Corp’s equipment acquisition and combat 
development processes. The evolutionary acquisition approach to command and control 
was adopted. A "build a little, test a little, field a little” strategy was put in place. [Ref. 
11] 

Section 1 will describe the evolutionary acquisition concept and discuss the 
advantages of it. The advantages and disadvantages of Non-Developmental Items and 
Commercial-Off-The-Shelf products will be presented in Section 3 and Section 4 will 


discuss how Evolutionary Acquisition will effect C* systems. 


1. Evolutionary Acquisition 
The "Evolutionary Acquisition” concept is a "build a little, test a little, field 
a little" approach using off-the-shelf equipment and software where applicable. 
Evolutionary Acquisition is defined as: 


An acquisition strategy which may be used to procure a system expected to evolve 
during development within an approved architectural framework to achieve an 
overall systems capability. An underlying factor in Evolutionary Acquisition is the 
need to field a well defined core capability quickly in response to a validated 
requirement, while planning through an incremental upgrade program to eventually 
enhance the system to provide the overall system capability. These increments are 
treated as individual acquisitions, with their scope and context being the result of 
both continuous feedback from developing and independent testing agencies and the 
uséraga [Refs 2p e2 3] 


18 


Evolutionary acquisition is an alternative acquisition process used to acquire 
C* systems that are expected to evolve during development and throughout their 
operational life. Figure 2 graphically represents the application of an evolutionary 
acquisition approach. The initial preliminary system architecture is segregated into 


planned increments. Those increments are then refined, funded, and developed in stages. 


fRef. 13] 
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Figure 2: A Model of Evolutionary Acquisition 
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2. Advantages of Evolutionary Acquisition 


There are several reasons for choosing an evolutionary acquisition approach: 


a. Lessons Learned From Past Failures 
The Marine Corps’ attempt at the "big system approach" for acquiring 
the MIFASS* system has failed miserably in the past at extreme cost. [Ref. 14] It was 
simply too hard to adjust requirements and specifications to keep up with both user 
demand and technology, and quickly incorporate these adjustments into a system. [Ref. 
15:p. 16] Using Evolutionary Acquisition, improvements or changes can be made at the 
next incremental upgrade and can be made easily if the onginal core design was built 


with the changes in mind. 


b. Lack of Complete List of Defined Requirements 
A complete list of C*’ automation or support requirements would be 
impossible to generate. The introduction of new technology and procedures makes old 
tasks easier and opens the door to provide new capabilities. This makes it difficult to 
predict the final requirements. [Ref. 15:p. 16) By using Evolutionary Acquisition, the 
user Can provide timely, accurate feedback of what he/she wants, needs, and actually 


uses. This feedback can be applied to the next increment and tested. 


* MIFASS was a subsystem program under MTACCS which failed for several reasons in 
1987. A comprehensive discussion of MIFASS can be found in Chapter II of Reference 14. 
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c. Political Acceptance of Evolutionary Acquisition 

The use of Evolutionary Acquisition as an alternative acquisition strategy 
is consistent with the guidance of the Office of Management and Budget Circular A-109, 
DoD Directive 5000.1, and with Defense Acquisition Circular 76-43. Evolutionary 
Acquisition encourages regular and continual interaction with the Deputy Program 
Managers’, requirements proponents, users, developers, testers, and logisticians. It 
encourages the consideration of Non-Developmental-Items (NDI) and Commercial-Off- 
the-Self (COTS) material where applicable. [Ref. 15:p. 16] By this continual 
interaction, the risk of spending a large amount of resources with no measurable return 
is reduced. The program is reviewed by all concerned at each increment. Those 
responsible for certain fields will have to interact repeatedly with those responsible for 


the other fields that effect them. 


d. User Response is Quickly Incorporated 
By starting with equipment and procedures the user is already familiar 
with, and incorporating a limited amount of change at each increment, the user can easily 


assimilate and evaluate the change, providing appropnate and accurate feedback. 


e. Capabilities are Fielded Faster 
Evolutionary Acquisition permits faster fielding of core capabilities to 
the user. It allows building on existing equipment and systems to quickly field a useful 


core capability and concurrently develop component systems, capitalizing on the ability 


> Deputy Program Managers are responsible for subsystems of a major acquisition program. 
They report to the Program Manager (PM). 
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to incorporate component systems as they complete their individual development phases. 
This permits new technology to reach the user at a rate that is much faster than currently 


possible. 


3. | Non-Developmental Items and Commercial-Off-The-Shelf Products 
Non-Developmental Items and Commercial-Off-the-Shelfproducts are generic 
terms that describe material available from a variety of sources with little or no 
development be the government. These are items that are either available in the 
commercial market place or from other services. 
According to William H. Taft IV°, "The use of Off-The-Shelf sources is a 
major initiative of the Department of Defense [Ref. 16:p. 103]. There is considerable 
motivation to pursue this element of acquisition strategy wherever possible. Non- 


Developmental Items yield several benefits: 


1. The time in development and the time to fielding is greatly reduced. 
2. User’s requirements and needs can be met and satisfied quickly. 
3. Costs for Research and Development are reduced. 


4. Current, state of the are technology is used and fielded. [Ref. 17] 


° Former Deputy Secretary of Defense. 
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However, there are risks involved with using Non-Developmental Items. 
These include: 

1. Cost and performance tradeoffs to accommodate the use of NDI components in 
production. 

2. The resulting proliferation of hardware and software can cause logistic support, 
training, and configuration management problems and possible increased life 
cycle costs. 

3. Safety deficiencies may occur because the NDI was not built specifically for a 
military environment. [Ref. 17] 

The benefits of using NDI should aid in the fielding of C’ systems 
tremendously. The risks are being minimized through the use of the common hardware 


and common software. By restricting the amount and type of each, many of the 


logistical and training burdens are alleviated. 


4. The Effect on C° Systems 
Mest C’ systems that are procured today and in the future will undoubtedly 
incorporate incremental evolutionary upgrades during their useful life cycle. 
Evolutionary Acquisition will be the strategy used to accomplish this. Bngadier General 
Edward Hirsch’, USA (Ret.), wrote in an article in Signal magazine: 
Evolutionary Acquisition 1s not a cure-all for the real or perceived ills of the U. 
S. acquisition process; but it does hold some promise to help field command and 


control systems sooner, at lower cost and with higher user satisfaction than other 
approaches. [Ref. 12:p. 23] 


’ Director, Center for Acquisition Management Policy, Defense Systems Management 


College at the time of publication of the article. 
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Evolutionary Acquisition has gained wide recognition as a strategy that 


provides the flexibility necessary to adapt evolving C°® systems. 


E. THE OPEN ARCHITECTURE ENVIRONMENT 


1. Overview 

A current approach to eliminating the problems of incompatibility, while 
transcending the problems of centralized systems, is called the "open systems" approach. 
There is a trend within the industry to develop products according to government, 
international, and industry standards. Users, vendors, and government standards 
organizations are encouraging the development of open system architectures. According 
to the International Organization for Standardization and the International Electrotechnical 
Committee (ISO/IEC), an open system is a system that complies with the requirements 
of a given set of universally accepted standards for communication and interacting with 
other open systems. Advantages of adopting open system architecture standards are the 

following: 
1. Increased competition results from the variety of vendors manufacturing 

products to meet the specified standards. 


2. Interoperability and portability are attainable only with systems using the same 
standards. 


3. Open systems support a multivendor environment, which reduces the chance that 
the government will be dependent on a single contractor. 


Although a potential logistics risk is created by a multivendor environment, this can be 


managed by requiring that all products purchased be contained on a list previously 
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established by the government. [Ref. 18:p. 2] The principle disadvantages of using 
standards are: 

1. A standard tends to freeze the technology. By the time a standard is developed, 
subjected to review and compromise, and promulgated, more efficient 
techniques are possible. 

2. There are multiple standards for the same thing. This is not a disadvantage of 
standards per se, but of the way things are currently done. Fortunately, in 
recent years, the various standards-making organizations have begun to 


cooperate more closely. Nevertheless, there are still areas where multiple 
conflicting standards exist. [Ref. 19:p. 18] 


2. The Effect on C* Systems 

Currently evolving open system standards include POSIX* interfaces, 
GOSIP’ data communication protocols, the ADA programming language, SQL data 
management systems, X-Windows User interfaces, Motif Graphic services, and X.400 
message handling systems. [Ref. 8:p. 3-61] Since these standards are still evolving, C° 
systems Feycloped in an open systems architecture today should have an integration plan 
that allows for the smooth incorporation of future evolving standards. 

The use of open systems standards such as GOSIP is now a federal 
information-processing standard (FIPS) and is mandatory for use on government 
procurements [Ref. 19:p. 27]. C°® systems that are developed using open system 


architectures reduce system integration costs; increase freedom of choice in selecting 


> Portable Operating System Interface; K denotes its UNIX origin. 


* Government Open System Interconnection Profile. 
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vendors; protect investments in software, data, and people; and enhance availability, 


quality, and variety of complementary products. [Ref. 20] 


F. CURRENT C> SYSTEM EVALUATION FRAMEWORKS 
This section will discuss some of current frameworks used today for evaluating C? 


systems. 


1. The Mission-Oriented Approach (MOA) 

The Mission-Oriented Approach is a framework for formulating requirements 
in order to achieve the desired balance among mission support, technical capability, and 
resources. This approach systemically and consistently addresses four interrelated 
questions (see Figure 3). 

First, it addresses the question "What are we trying to achieve operationally?" 
This question must be answered by high-level decision makers in the context of relevant 
policy and political-military considerations. The response is generally cast in terms of 
a set of strategic capability objectives for employing forces. These force capability 
objectives provide the standards against which the capabilities of existing and proposed 
packages of information systems can be measured. 

The second phase of the requirements process addresses the question: "How 
Should we perform the mission operationally?" This question must be addressed by 
operational personnel who must formulate concepts of operations at multiple levels: 
Strategic (e.g., the concept of forward defense), operational (e.g., mix and emphasis 


among missions), and functional capability (e.g., ability to sense, assess, plan, and direct 
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to achieve mission goals). The capability objectives for each of these levels must be 
derived self-consistently, beginning with specified strategic capability levels, based on 
likely adversarial operations, friendly concepts of operation, and environmental factors. 

The third phase of the requirements process addresses the question: "What 
technical capability is needed to support the operation?" This phase should employ 
technical personnel to translate the operational capability objective levels into the desired 
technical attributes of the information systems needed to implement those capability 
levels. These technical capability objectives are derived using the existing and projected 
technical characteristics of adversary forces, friendly forces, and environmental factors. 

The fourth phase of the requirements process addresses the question: "How 
is the technical job to be accomplished?" As a foundation for this question, technical 
deviations are identified be comparing the technical capabilities of existing and 
programmed information systems to the time varying technical capability objectives 
identified in the prior phase. Based on those deviations, technical and programmatic 
personnel can formulate technical requirements that are consistent with assumptions on 
available resources and schedule. If these communities are to perform this task credibly, 
it 1S critical that they be cognizant of the unique characteristics of information systems. 
These systems are characterized by internal and external interfaces that are complex, 
frequently changing, and at multiple organizational levels. Humans are integral parts of 
these systems and their interfaces with one another and the machines are highly 
interactive, complex, and changing. The technology that underlies these systems (e.g., 


computers, communications, displays) is undergoing revolutionary change and emerging 
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systems are very software intensive. Thus the technical and programmatic communities 
face the challenging task of formulating technical requirements that balance technological 
risk and obsolescence. [Ref. 21:pp. 119-128] 

After initial answers to these four questions have been developed it is 
important to iterate through the framework. This iteration is needed to identify and 
resolve issues that require additional analysis across communities (e.g., interaction 
between the operational and technical communities) and within communities (e.g., 
technical tradeoffs between risk and potential obsolescence). [Ref. 22:pp. 2-5] 

The Mission-Oriented Approach is an attractive candidate for formulating C° 
system requirements in an evolutionary environment. A variation of this approach has 
been successfully used by U.S. Pacific Command (USPACOM) to help identify and 
define C°I capabilities and systems that their warfighters need to meet USPACOM 
mission responsibilities. [Ref. 23] 

While the Mission-Oriented Approach is well suited for requirements 
determination, it is not particularly well suited for the evaluation of alternative C° 
systems, which is the focus of this thesis. But, the approach could be used to verify or 


validate current and future C* system requirements. 


2. The Modular Command and Control Evaluation Structure (MCES) 
The Modular Command and Control Evaluation Structure (MCES) is a 
general approach to evaluating C* systems which has been successfully applied to a 
number of issues concerning C° system planning, acquisition, testing and operation. [Ref. 


24] It augments traditional analysis by providing a series of seven steps or modules to 
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evaluate alternative C* systems and architectures. These modules guide analysts who 
might otherwise focus prematurely on the quantitative model rather than the problem 
definition and the specific measures needed to discriminate between alternatives. The 
seven steps of the MCES are briefly described below including the product of each 
module. 

The MCES begins by identifying the objective of a particular application. 
This leads to a formal problem statement. The second step is to bound the C* system 
involved, by producing a complete list of system elements at several levels. The third 
step is building a dynamic framework that identifies the relevant C* process-a set of 
functions. The fourth step combines the results of steps two and three by integrating the 
system elements and the process functions into a model or representation of the C 
system. The product of this module is at least a complete descriptive conceptual model 
and sometimes a complete mathematical model. The next (fifth) step is to specifically 
identify measures of performance, effectiveness and force effectiveness at the 
corresponding levels of the C* system and function. The sixth step is to generate results 
or values for these measures by testing, simulation, computational modeling or subjective 
evaluation. Finally, the various measures are aggregated and interpreted in the last step. 
The seven steps of the MCES are performed iteratively with the decision maker as shown 
in Figure 4. 

In an area such as C*, standard language and paradigms are difficult but 
necessary. The MCES was developed by a team of experts from industry, government 


and academia and was endorsed by the Military Operations Research Society. It presents 
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difficult concepts in a standardized way that is easily absorbed by both new practitioners 


and managers. MCES has potential for reducing mis-understandings of the purpose and 
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mis-applicability of analytical results. This is important when issues of great diversity 
of nature, size and level of detail are being considered. Standardization of analytical 
procedure can be advantageous if based on a comprehensive and rigorous methodology 
such as MCES. The MCES can be used for studies ranging from the quick conceptual 
level to the complete quantitative study. [Ref. 25:pp. 1-3] 

The MCES offers a comprehensive framework for developing robust 
measures for complex systems, but it doesn’t provide specific guidance on evaluating 
systems that will change over time. An interesting similarity exists between the Mission- 
Oriented Approach and the Modular Command and Control Structure. Note that the first 
two questions of the MOA and module three of the MCES both deal with C’ functions. 
Also, the second two questions of the MOA and module four of the MCES deal with C 


components or capabilities to support those C? functions. 


3. The Current COEA Evaluation Framework 
The following sections will present the methodology used by the Cost and 
Operational Effectiveness Analysis (COEA) team for the evaluation of the Marine Corp’s 


TCO program discussed in Chapter I. 


a. Approach 
Each alternative was evaluated in three areas: effectiveness, cost, and 
risk. The effectiveness evaluation was conducted by an evaluation team exercising each 
of the alternative systems in a laboratory environment. The cost evaluation was 


conducted by collecting cost data from developers; the TCO program office; Marine 


a2 





Corps Tactical Systems Support Activity (MCTSSA); Marine Corps Logistics Base, 
Albany; the MTACCS Common Application Support Software program and MTACCS 
Common Hardware Support programs; Marine Corps Operational Test and Evaluation 
Activity; civilian vendors; and the Marine Corps Cost Factors Manual. This data was 
validated and expanded using the Constructive Cost Model and the Conversion Cost 
Model. Both of these models predict software development costs based on system size 
and complexity. The Conversion Cost Model specifically addresses costs associated with 
software conversion. Discounted life cycle costs were estimated using the Marine Corps 
Summary Version Life Cycle Cost Model. The risk assessment assessed the technical 
and program risk associated with modifying each of the alternatives to satisfy the TCO 


requirement. 


b. Effectiveness Analysis 

Evaluation of the effectiveness of TCO alternatives focused on 
determining the operational effectiveness, the operational suitability, and the life cycle 
supportability of each alternative. To this end, measures were developed to support 
assessments of capability in each of these three areas. Measures of operational 
effectiveness assess the military utility of each alternative. Measures of operational 
suitability assess how well each alternative would operate in an austere environment 
without adversely impacting mobility, maneuverability, or operational flexibility. 
Measures of life cycle supportability assess sustainability, maintainability, and growth 
potential. These measures were based upon the TCO requirement as documented in the 


TCO MNS. Overall rankings were assigned. 
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c. Cost Analysis 

Life cycle cost estimates were developed for each TCO alternative. 
These show the costs to satisfy TCO core requirements and the incremental cost to satisfy 
follow-on requirements. Life cycle costs include research, development, testing, and 
evaluation (RDT&E); procurement; and 15 years of operations and support (O&S). 
RDT&E costs are associated with software development, operational test and evaluation, 
system integration and assembly, and program management. Procurement costs include 
hardware, spares, and repair parts, commercial software, contractor-provided training, 
and first destination transportation. Operations and support costs include software and 
hardware maintenance, operator training, and secondary destination transportation. 
Estimates were based on implementation of MCHS Class B hardware and MCASS 
software. An additional $1,500,000 per year has been estimated to support evolutionary, 
system improvements. The core, follow-on, evolutionary and total life cycle costs for 


each TCO alternative were calculated. All costs are in FY 93 constant budget dollars. 


d. Risk Analysis 
The TCO MNS defines a two component requirement. One component 
of the requirement is for automated tools to support operations planning and execution. 
The other component is for connectivity across the battlefield using tactical 
communications and for interoperability with other C’ systems. These two components 
are interdependent, and each must be met to satisfy the TCO MNS. Since 
communications connectivity and interoperability will be provided through use of 


MCASS modules (and the Tactical Network Server (TNS)/Tactical Communications 
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Interface Module (TCIM)), the risk associated with satisfying the connectivity and 
interoperability portion of the requirement is consistent across alternatives. The risk 
associated with providing the required automated support for operations planning and 
execution varies by alternative. The total risk associated with any alternative is a 
function of the program risk that an individual alternative can not provide the required 
automated tools and the risk that MCASS modules will not provide the required 
connectivity and interoperability. The total risk function is defined as the maximum of 


the program risk and the MCASS risk. 


e. Trade-Offs 
The analysis team then performs a trade-off analysis between the base 
case and the TCO COEA alternatives by analyzing the capability rankings of each 
alternative in terms of operational effectiveness, operational suitability, and life cycle 


supportability; life cycle costs; and the risk assessment. 


f. Decision Criteria 
Alternative selection is based on system capability (operational 
effectiveness, operational suitability, and life cycle supportability); life cycle cost; and 
program risk. 
g. Recommendations 


The decision criteria will then lead to recommendations’”. 


10 The actual recommendations of the COEA team were not officially published at the time 
of this writing and are outside of the scope of this thesis. 
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The methodology used by the COEA team is a comprehensive and 
effective way to evaluate alternative C* systems. It involves evaluating the alternatives 
based on their current configurations. Projected costs of adding some of the required 
core capabilities to the alternatives were computed and used in the evaluation, but 


planned upgrade paths of the alternatives were not considered in the analysis. 


G. CONCLUSIONS 

This chapter presented a discussion of the technology initiatives that will impact C’ 
systems. The Evolutionary Acquisition concept was introduced and topics such as Non- 
Developmental-Items, Commercial-Off-the-Shelf products, and open architecture 
Standards were presented. A representative sample of some current evaluation 
frameworks were then discussed. 

It is important that the procurement environment for C* systems be understood by 
the evaluators. Important factors of the procurement environment that effect C’ systems 
include; the recent increased rate of technological change, the mandated use of the 
Evolutionary Acquisition concept, the use of NDI and COTS products, and the evolving 
open architecture standards. The following conclusions can be made in regard to the 
environment in which C® system are procured: 

I. Uhatee: _— must capitalize on emerging technologies to remain mission 
capable. 


2. That C° systems will incorporate evolutionary upgrades throughout their useful 
lifeseycle: 
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3. That most of these evolutionary upgrades will be composed of NDI or COTS 
products that adhere to "open system" standards. 

The Mission-Oriented Approach, the Modular Command and Control Evaluation 
Structure, and the COEA team’s evaluation approach represent the current state of C° 
systems evaluation. It can be concluded that none of these frameworks or methodologies 
specifically deal with the temporal component of C* systems. One of the most difficult 
aspects of C° systems is that they will continually change over time (given evolving 
technologies, standards and applications). No framework currently exists that specifically 
deals with evaluating the upgrade paths of C’ systems. 

As discussed, C* system procurements today can be viewed as upgrades to existing 
C* systems. Even large procurements that make sweeping changes will be incremental 
and evolutionary. Therefore, it is useful to explicitly embrace the evolutionary upgrade 
concept, and develop a framework for comparing alternative upgrade paths rather than 


alternative static C* systems. The following chapter presents such a framework. 
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I. A NEW FRAMEWORK 


A. INTRODUCTION 


1. Purpose of this Chapter 

The purpose of this chapter is to present a useful framework for evaluating 
evolutionary upgrade paths of C* systems. As discussed, most C? wen procurements 
will be evolutionary, and both existing and new C’ systems will go through many 
changes during their useful life cycle. As emerging technologies mature, C’ systems will 
be incrementally upgraded as soon as is feasible in order to remain as mission capable 
as possible. Procurement alternatives that capture this temporal effect are evolutionary 
upgrade paths. 

The framework presented here is a functionally-oriented, capability-based 
approach intended to be a useful step by step method that produces information about 
alternative evolutionary upgrade paths that is useful to decision makers. The level of 
discussion is at a generic and sometimes abstract level so that wide applicability can be 
maintained. 

2. The Need for Effective Evaluation 

The procurement of an extensive C’ system or an extensive upgrade to an 
existing C’ system is an expensive proposition. A bad decision now could cost millions 
of dollars in the future, therefore, a thorough and effective evaluation framework 1s 


needed. Chapter II highlighted the major issues that effect C’ systems and their 
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evaluation. It can be seen that just about all new C* systems will be procured over time, 
and will employ incremental evolutionary upgrades to keep up with technology. This 
temporal component of C* systems is a difficult aspect to evaluate. There are currently 
no widely accepted methods that accurately evaluate C’ systems based on their upgrade 
paths. This framework will mainly focus on this temporal component and present a set 
of procedures for evaluating C* systems by viewing them as evolutionary paths toward 


some future goal or target system. 


3. Methodology 
In presenting the framework, some key terms used in the explanation of the 
framework will first be defined. Then, a step by step generic procedure will be 
presented along with recommendations on the preferred methods for accomplishing those 
steps. The methods developed in this framework are suited for use with virtually any C° 


system or subsystem. 


B. THE FRAMEWORK 
In presenting the framework, several terms are used that require definitions so that 
the concepts presented can be understood by the reader. 
1. Definitions 
ee Oe ie 
A C system is a collection of equipment, personnel, procedures, 
facilities, and communications that provide a commander the tools essential for planning, 


directing, and controlling operations of his assigned forces. 


oy 


For the purposes of this framework, C* systems can be viewed as a collection 
of tools that provide automated support to those functions that commanders have always 
performed (e.g., planning, directing and controlling his forces). The focus of most 
acquisition related C* system evaluations are in the area of hardware and/or software 
products that provide automated support to C* functions that support the warfighter. 
Therefore, the evaluation problem that this framework is tailored to deals with those 


decisions regarding which hardware and/or software products to buy or invest in. 


b. C Functions 

The C? functions that this framework will focus on are those functions 
that commanders have always performed (e.g., develop an Operations Plan or 
disseminate an Operations Order). This is done so that the warfighter’s needs remain in 
focus. As discussed, C* systems provide automated support to C° functions. For the 
purpose of this discussion, when the automation of a function is referred to, it could 
either mean just automated support to that function or the full automation of that 
function. In order to identify the level of functions to be used in this framework, 


functional decompositions may be required". 


c. Technological Capabilities 
In order to provide automated support to C’ functions, the system must 
afford a set of capabilities that will be called technological capabilities (e.g., word 


processing capability, interoperability with another system, digital mapping, etc.). Most 


'! Functional decompositions will be explained later in the chapter. 
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capabilities that new C* systems will possess are a product of some new technological 
advance (e.g., fiber optics, open systems standards, bubble memory, etc), therefore, they 
will refer to as technological capabilities. In order to provide automated support to a 
function, a set of technological capabilities is required. For example, to automate the 
production of overlays, technological capabilities such as pen/mouse user interface, 
digital mapping, high resolution display, iconic and symbology database, and hard copy 


capabilities are just a few of the technological capabilities required. 


d. The Target System Functions and Capabilities 

The target system is a system that provides the desired level of automated 
support to each of the C°* functions within the system boundaries at some future planning 
horizon. 

The target system functions are the set of C’ functions that are automated 
in the target system, and the target system capabilities are the technological capabilities 
required to Peeve the automated support. 

The target system functions and capabilities will be displayed in a 
function/capability table so that the relationship between them can be clearly seen. 
Figure 5 illustrates what this table will look like. For example, referring to Figure 5, 


in order to automate function F1, technological capabilities TC1 and TC3 are required. 


e. Current or Base System 
A current or base system is a system that is currently in use or one that 


could be bought today. It usually only automates a subset of the functions listed in the 
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Figure 5: Capability/Function Table 
target system’s function/capability table described above. In an evaluation, current or 
base systems are viewed as alternative base systems. These alternative base systems are 
those systems that can be reasonably expected to some day obtain the level of automation 


that is required in the target system. 


f. Migratory Systems 
Migratory systems are future upgraded versions of a particular base 
system and usually consists of the base system plus some additional technological 
capabilities. Several migratory systems could spawn from a base system given different 


evolutionary upgrade plans. 
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g. Viable Upgrade Path 
A viable upgrade path is an incremental series of upgrades to a base 
system that will eventually lead to a fully functional target system. A viable path is one 
that is reasonable in terms of cost and risk and is agreed upon by the operational, 
technical, and the programmatic experts. Effective cooperation is crucial in the 
development of these viable upgrade paths. Figure 6 illustrates how each alternative base 


system could take different paths toward achieving the required target capabilities. 


ALTERNATIVE BASE MIGRATORY SYSTEMS | TARGET SYSTEM 


Some 





Figure 6: Illustration of Viable Paths 
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h. Value 
The term value will be used to represent the benefit gained by a force 
when a particular function is provided the required level of automated support. This 
added value or benefit to the force due to the automation of a function could be 
measured in terms of a Measure of Force Effectiveness (MOFE)” or in terms of a 
relative importance or weight’®. In either case, a value or benefit to the force, must be 


associated with each target system function. 


i. Costs 

Two types of costs are referred to in the discussion of the framework. 
The first type of cost focuses on procuring a particular alternative base system today. 
This cost should be an estimated life cycle cost of the alternative base system as it is 
configured today. It should include the costs associated with research, development, 
testing, and evaluation (RDT&E); procurement; and 15 years of operation and support 
(O&S)'*. ebes associated with hardware procurement, hardware and software 
integration, system fielding, hardware and software maintenance, and system training and 
operations can be collected from government organizations, government publications, and 
private industry. All cost data should be normalized to the current constant budget 


dollars. 


'? For example, force exchange ratio, number attackers attrited per unit time, etc. 
'5 Methods for obtaining relative weights will be discussed later. 


‘4 The 15 year life was taken from the COEA Final Report (Draft) 
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The second type of cost used in the framework is the cost of adding 
technological capabilities to alternative base systems. The same kind of life cycle costs 
as discussed above should be used, but it should focus only on the costs associated with 
a particular technological capability and its integration into an existing system. The cost 
of adding a technological capability only needs to be normalized to the year in which it 
is projected to be added to a system. Methods for discounting these costs will be 


presented later. 


2. The Framework 

In order to evaluate alternative systems that will change over time, the ideas 
of a current or base system, migratory systems, and a target system help frame the 
problem. The current system is the system currently in use or one that could be bought 
today to fulfil some mission need. All systems or subsystems in place today will some 
day either become technologically obsolete or no longer meet the needs of the user. 
When the rie comes to replace or upgrade that system or subsystem, decisions must be 
made as to how to proceed. This framework presents a method that could be useful to 


decision makers in making that decision. The framework contains four top level steps: 


1. Define target system functions and capabilities. 


2. Define all viable upgrade paths from each alternative base system to the target 
system; each path becomes a candidate path. 


3. Develop a discounted value and a discounted cost for each candidate path. 


4. Select the candidate path that maximizes value subject to a stated cost, resource, 
and risk constraints. 
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A brief summary of the steps shown in Figure 7 follows. 


DEFINE 
TARGET 
SYSTEM 


Functions/Capabilities & Value of Functions 


Alternative Systems and their Viable Patns 


Discounted Value and Cost of Each Candidate Path 


Candidate Path Selected that Maximizes Value s.t. Cost 





Figure 7: The Steps of the New Framework 


The first step of the framework begins by defining the target system in terms 


of the functions it should automate and the technological capabilities required to automate 
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each of those functions. The value of each of those functions is then determined. The 
output of this step is a table highlighting the relationships between the target system’s 
technological capabilities and the functions it must automate along with the value of each 
function. The second step of the framework begins by identifying all of the alternative 
base systems in terms of the technological capabilities they possess. All viable paths to 
the target system that spawn from each alternative are then determined. The output of 
this step is an enumeration of all viable candidate paths. The third step of the framework 
involves assigning functionally derived values and capability derived costs to each 
candidate path at discrete time intervals. These values and costs are then discounted to 
the present. The output of this step is a discounted value and cost associated with each 
candidate path. The last step of the framework involves filtering out the candidate paths 
that do not meet the cost constraint and then picking the candidate path that has the 
greatest value. This should result in the candidate path that provides the greatest value 
to the force given a particular cost constraint. 

The above steps of the framework are expanded upon in the following 


sections. 


a. Define Target System Functions and Capabilities 


Figure 8 illustrates this step. 


(1) Functions and Capabilities. In the acquisition world, descriptions 
of target systems are easily found in documents like the Mission Need Statement (MNS) 


and the Operational Requirements Document (ORD). These documents highlight needs, 
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Figure 8: The New Framework - Step 1: Define Target System 


requirements, and constraints for a given system. In the case of C* systems, from the 
requirements, a list of functions that require automated support can be derived. This 
automated support is provided via capabilities. The functions derived from the 
requirements are normally those that commanders and their staffs have always done 
(e.g., prepare an operations order and disseminate it, develop courses of action, decide 


on course of action, direct his forces, etc.). The functions’ should be chosen at a level 


‘> At this point, the author will assume that the functions can be automated independently, 
realizing that interdependence really exists. 
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that will allow a manageable sized list of required technological capabilities to be 
defined. Functional decompositions are usually required. Figure 9 illustrates what a 


simple generic functional decomposition looks like. 


FUNCTIONAL DECOMPOSITION 





Figure 9: Example of Generic Functional Decomposition 

Once the functions are identified, the technological capabilities required to provide the 
required automated support can be determined. Through elicitation of technical and 
operational experts, a list of the capabilities required to automate each function at the 
required level can be obtained. It should be realized here that some of the capabilities 
in this list may not be available yet, given the current state of technology. 

After completing the above procedure, a function/capability table can be 
constructed that shows the relationships between the functions and the technological 
capabilities. Table I illustrates what this table looks like. In the column that corresponds 
to an operational function, an X is placed in the boxes corresponding to the rows of the 
technological capabilities required to automate that function. A function cannot be 
automated at the required level unless all the technological capabilities with an X in that 


function’s column are provided by the system. For example, from Table I, function F1 
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Table I: FUNCTION/CAPABILITY TABLE 


Operational Functions 


Technological 
Capabilities 











cannot be adequately supported with the desired level of automated support unless the 


system possesses technological capabilities TC1 and TC2. 


(2) Value of C’ Functions. Once the relationship between target system 
functions and capabilities is known, the next part of this first step is to determine the 
value of each function. The goal here is to assign a value or benefit added to the overall 
force when a particular function is automated. 

One method to accomplish this would be to design an experiment 
or construct a model that would allow the assessment of the effect on overall force 
effectiveness given that a particular function is automated. Runs of the experiment or 
model could be made when the function is performed without automated support and 
then again with the automated support’®. The outcomes of each case could be compared 


and a MOFE assigned as the value of the function. This method would be done for all 


'© A typical question that could be answered is, "What effect does automating overlays have 
on the overall effectiveness of the force?” 
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of the target system functions. But, it obviously would require a substantial expenditure 
of time and money, both of which are usually limited. 

Another method requiring less time and money would be to elicit 
relative values!’ or the importance of each function from experienced operational 
experts. The idea is to elicit from the experienced experts the relative importance to the 
operational force of automating each target system function. Various methods of 
elicitation include closed questions, open questions, brainstorming guided brainstorming, 
and group consensus. [Ref. 26] 

Other methods such as the Analytic Hierarchy Process (AHP) or 
the Simple Multi-Attribute Rating Technique (SMART) can also provide tools to aid in 
obtaining the relative value or weight of each function to the force. [Ref. 27] These two 
methods structure the problem as a hierarchy which serves as a useful aid to 
understanding problems and fostering discussion about them. The process can reveal 
issues which have not previously been explicitly stated. AHP utilizes pair-wise 
comparisons of attributes'*, where as SMART elicited values on a 0-100 scale for each 


attribute. The process used by both is easy to understand and decision makers have been 


17 The term relative value or weight has, at times, not been well received by professionals 


in the acquisition and operational fields because arguments among steering committee members 
have lasted for hours on what weights to assign. This should not be viewed as bad, in fact, this 
is one of the advantages of this kind of method because it forces decision makers to deal with 


difficult issues that may have not been explicitly stated before. 


'8 Attributes, in the case of determining relative values of functions, would refer to low 
level functions that result from the decomposition of higher level functions. 
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comfortable with it'®. Applying either of these methods would result in a list of the 
relative values or weights for each function. These methods emphasize the point that the 
value of a system (through automation of functions) is what it does for the user. This 
value can be estimated via the user’s perception of the relative importance of the various 
areas in which the user benefits from the system. [Ref 28] 

Table II illustrates what the results of this step should produce. In 
summary, the first step of this framework results in defining the target system in terms 
of the C* functions it supports and the technological capabilities required to provide 


automated support to those functions. Furthermore, the value of each function is 


Table I: FUNCTION/CAPABILITY TABLE FOR THE TARGET SYSTEM 


Technological 
Capabilities 





determined in terms of a MOFE or by a weight or relative importance to the force. 


The added V1, V2, ... , VN in Table II represent the value of that particular function. 


19 Case studies can be found in Reference 27. 
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This table provides the information needed in subsequent steps of the framework. The 


next step involves defining candidate paths. 


b. Define Candidate Paths 

Figure 10 illustrates this step. The step of defining candidate paths 
requires two tasks, first the alternative base systems are determined and then the 
candidate paths that spawn from these alternative base systems are enumerated. The goal 
of this step is to come up with a list of the viable (or reasonable) candidate paths that will 
lead to obtaining the capabilities established in the definition of the target system 
functions and capabilities from step one. 

This step begins by identifying the alternative base systems that will be 
considered in the evaluation. These alternatives should be systems that preferably 
already meet some of the requirements of the target system. The alternative base 
systems should be chosen by the experts with the target system in mind. The concept 
is that each chose alternative base system could someday fulfill all the requirements of 
the target system by incrementally adding future technological capabilities. Initially, each 
alternative base system will possess a set or vector of technological capabilities, TC. 
Let time be discrete (t = 1,...,T) where T is the planning horizon, then at each date t, 
there is a vector of technological capabilities TC, generated by each alternative system. 
Each alternative system will evolve over time given that there is technological change 
over time (and hence automation opportunities). Several viable paths could spawn from 
each alternative system. Each one of these viable paths will become a candidate path and 


could be developed by creating a specific scenario of technological change and 
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Figure 10: The New Framework - Step 2: Defining Candidate Paths 
automation for its base system. Each candidate path should satisfy the current cost, 
resource, and msk constraints. 

The Figure 11 illustrates that each particular alternative base system will 
migrate towards the capability of the target system by following one of several reasonable 
and viable paths of upgrades. Each candidate path begins at an alternative system. As 
technological capabilities are added, migratory systems are realized until finally the 
capabilities of the target system are obtained. At each date t, each candidate path has 


associated with it a new vector or set of technological capabilities. This list of 
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Figure 11: The Migration of Alternative Base Systems 


capabilities may succeed in providing the capabilities required to provide automated 
support to more target system functions. Therefore, each candidate path contains a 
changing list of technological capabilities and a changing list of functions that it can 
provide the required automated support to. The next step of the framework involves 


determining the overall value and cost of each candidate path. 


c. Get Values and Costs 
Figure 12 illustrates this step. The goal of this step is to derive a single 


overall discounted value and a single overall discounted cost for each candidate path 
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constructed in step two of the framework. Methods for determining the discounted 


values and costs will be presented in the following sections. 


fs DEVELOP VALUE AND COST 


@ EACH FUNCTION PROVIDED HAS A VALUE 
@ EACH CAPABILITY HAS A COST 
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Figure 12: The New Framework - Step 3: Develop Value and Cost 


(1) Value. Since the value of each function defined in the target 
system is now know from step one, the overall value of any candidate path depends on 
the functions it succeeds in automating and when they are automated. Any set or vector 
of technological capabilities, TC, can be easily assigned a value by adding the values of 
the functions that the set of capabilities automates. Since each candidate path 1s actually 
a time series of TC vectors, at each time step there is a TC, (vector of technological 


capabilities at time t). Each successive TC, vector of a candidate path may provide the 
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capability to automate additional functions by the addition of more technological 
capabilities. So each candidate path can be viewed as a time series of upgrades 
(additional technological capabilities added) that incrementally automate additional 
functions until all the functions of the target system are given the required level of 
automation support (from the definition of the target system in step one). 

If each candidate path simply receives the value of a function when 


it succeeds in automating it, all paths will receive the same value since all candidate 
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Figure 13: A Way to Discount the Value of a Function 
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paths will eventually automate all of the target system functions. Clearly, it is more 
useful to the warfighter to provide automated support today rather that several years in 
the future. Measures used to compare paths should reflect this difference. Therefore, 
in order to make this a meaningful measure, a method of discounting the value of 
functions must be used. In order to develop a discounted value for the candidate paths, 
a value versus time curve for each function is needed. It is generally agreed that the 
sooner a system can automate a particular function, the more valuable that system will 
be to the user in terms of that function. That is, a candidate path that automates a 
particular function earlier than another should receive more value for automating that 
function sooner. Therefore, for each function, a kind of “utility” curve could be 
developed like that in Figure 13°. The lower curve could be used for functions that 
are more critical to the users. That is, if two candidate paths are being compared, the 
path that automates a function (utilizing the lower curve for its discounting) the soonest, 
will receive a far greater value than a path that automated the function later. Where as, 
if the upper curve was used, the difference in value between two paths would be less. 
For ease of calculations, the simplest case would be that at the present time (t = Q), the 
full value of a function is given if the vector of technological capabilities, TC), present 
in the alternative base system for a candidate path has all the capabilities required to 
automate that Finck If, on the other hand, the function is not automated until the 


planning horizon, say ten years (t = 10), by the vector TC,9, some residual fraction 


°° A thorough discussion of utility theory and its relationship to decisions under risk is 
contained in Chapter 11 of Reference 29. 
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(one-half is chosen for the illustration) of the value to the force of automating that 
function would be given to the candidate path. 

How this "utility curve" of the value of the function in Figure 13 behaves 
between the present time and the planning horizon is a function of the temporal 
importance or the time criticality of automating that function as discussed above. 

The discounted values, denoted DV, for each function are derived 
from each function’s utility curve and are a function of the time the system received the 
capability to automate that function. The following equation would be used to calculate 
the discounted value of a function if the linear relation 1n Figure 13 was chosen: 


V. 
DV,=V,-t ae (1) 


Where DV; is the discounted value of the i” function, V; is the 
value of the i* function at t = 0, and t is the year or time period that the candidate path 
successfully automates the function 1. 

The overall discounted value, ODV, of a particular candidate path 
would then be the sum of the discounted values of each function’’. To find the overall 
discounted value of the candidate path, the individual discounted values of each function 


are simply added. The following equation will be used: 


41 Still assuming that independence exists between functions. 
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N 
ODV=)> DV; (2) 


imi 
Where ODV is the overall discounted value of the candidate path, i is a 
counter for the individual functions, N is the total number of functions, and DV; is the 
discounted value of the i® function. 
This concept of functionally derived values can provide valuable insight into 
prioritizing the more important technological capabilities for future acquisition decisions. 
Candidate paths that receive relatively high values will undoubtedly benefit the user more 


than one with a lower value because the more important functions are automated sooner. 


(2) Cost. Costs used in this framework are derived from capabilities 
and are those discussed in Section 2, Paragraph 1. They consist of the cost of the 
alternate base system if bought today and the cost of adding a particular technological 
capability in the future to a given base system. Costs of adding a particular technological 
capability may be different for each alternative base system because each system may 
require different combinations of hardware and/or software to provide the required level 
of automation depending on the current configuration of the base system. As discussed 
earlier, the costs should include the costs associated with research, development, testing, 
and evaluation (RDT&E); procurement; and 15 years of operation and support (O&S)**. 
Costs associated with hardware procurement, hardware and software integration, system 


fielding, hardware and software maintenance, and system training and operations can be 


*2 The 15 year O&S time frame was used in the COEA Final Report (Draft). [Ref. 8] 
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collected from government organizations, government publications, and private industry. 
The cost of the alternative base system should be normalized to the current constant 
budget dollars, but the cost of adding the technological capabilities should be normalized 
to the year in which they are added to a candidate path. 

Discounted costs of adding technological capabilities are computed 


using the standard discounting function: 


DC;= 





1 | C, 3) 
a+ry 





Where DC; is the discounted cost of adding the j" technological 
capability, r is the discounting factor or interest rate, y is the year or time period, and 
C; is the cost of adding the j” technological capability to the system. 

To calculate the overall discounted cost of the candidate path, the 
initial cost of the alternative base system is added to the discounted cost of each 
technological capability that is added to the candidate path. The following equation is 
used to compute the overall discounted cost of a candidate path: 

M 
ODC=IC +}> DC; (4) 
F=0 

Where ODC is the overall discounted cost of a candidate path, IC; 
is the initial cost of buying the alternative base system, M is the total number of 
technological capabilities that are added to a candidate path, and DC; is the discounted 


cost of adding the j™ technological capability. Figure 14 illustrates these calculations. 
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CANDIDATE PATH 


BASE SYSTEM MIGRATORY SYSTEMS TARGET SYSTEM 


| TIME -2 Coed eeeeoceiegl 


COST VALUE 


(COST AND VALUES ARE DISCOUNTED TO THE PRESENT) 





Figure 14: The Discounting of Values and Costs 

The procedure for finding the overall discounted value and cost of a 
candidate path is straight forward. The first step involves determining when (or at which 
time periods) the candidate path will succeed in automating the functions of the target 
system. The second step requires the use of Equation (1) to compute the discounted 
value of each of the fecal The third step uses Equation (3) to calculate the 
discounted costs of the technological capabilities that are added to the system. The fourth 
and fifth steps use Equations (2) and (4) to compute the overall discounted value and cost 


of the candidate path. 
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The output of the above calculations is a single overall discounted value 
and a single overall discounted cost for each candidate path. The next step discusses how 


to select the best candidate path given this data. 


d. Select Candidate Path 
Figure 15 illustrates the final step. The above procedures will result in 
a list of the discounted values and costs for each candidate path. A simple, but common 
problem statement is to maximize value subject to cost, resource, and risk constraints. 


The rule or problem is stated as: 


Maximize: Value 
Subject to: @ Cost 
@® Resource 
@® Risk 


This would result in the candidate path that provides the user with the best 
possible Benefit within the established cost, resource, and risk thresholds. The method 
for selecting the best candidate path under this rule is to disregard the candidate paths 
that do not meet one or more of the constraints. Then select from the remaining 


candidate paths the one with the highest value. 
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f SELECT BEST CANDIDATE PATH 


@ SELECT CANADIDATE PATH SO AS TO: 


MAXIMIZE : VALUE 


- COST 
- RISK 
- RESOURCE 


CANADIDATE PATHS 





Figure 15: The New Framework - Step 4: Select Best Candidate Path 


3. Conclusions 
In the above discussion, a framework for evaluating alternative evolutionary 
upgrade paths was developed. Methods for defining a target system, developing 
candidate paths, and assigning values and costs to those paths have been presented. 
These values and ae can then be compared given a set of decision criteria and the 
"best" system with its associated upgrade path can be selected. It would then be up to 


the decision makers to consider any further issues before reaching their final decision. 


These kinds of decisions may be made many times (for each upgrade 
procurement). For each evaluation, some or all of the process will be repeated; if the 
functions to be supported have changed (which may be infrequent), the target system 
functions and capabilities could be modified, giving a new set of functions with 
associated values. In either case, technological advances will make new capabilities 
available, giving new sets of candidate paths with their associated discounted values and 
costs. 

The overall goal of evaluating alternatives is to pick the "best" alternative. 
For this framework, the "best" alternative is the system that provides us the best path 
(series of upgrades over time) to some target system by maximizing the value of the 
system (and system path) subject to cost, resource, and risk constraints. The value and 
cost of a candidate path that spawns from a base system will be measured in terms of the 
discounted cost and the discounted value of each upgrade path. This framework will help 
the decision makers by providing insightful and valuable information on the upgrade 


paths of the decision alternatives. 
4. Application of the Framework 
The above presentation was at a rather general and abstract level. The 
following chapter will provide a more concrete illustration of how this framework can 


be used to evaluate a real C* system, the USMC’s current TCO system. 
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VI. AN ILLUSTRATED EXAMPLE 


A. INTRODUCTION 


1. Purpose of this Chapter 
The purpose of this chapter is to provide an illustration of the framework 
described in Chapter III. The illustration will focus on the Marine Corp’s TCO system 
described in Chapter I. The illustration should clarify how the methods discussed in the 
previous chapter can be applied. Values and costs used in the illustration are not actual 
values and are included in order to facilitate the illustration. Furthermore, only a small 
sample of the functions and technological capabilities of TCO will be used in this 


illustration. 


2. The Problem 
The problem associated with the Marine Corp’s Tactical Combat Operations 
System is a common one. Most new military C* systems will require a Cost and 
Operational Effectiveness Analysis (COEA) to be done on the chosen alternative base 
systems. In the case of TCO, several alternative base systems were selected”. The 
TCO COEA team is currently performing an analysis on the alternatives and will 
recommend to the decision makers the alternative that best meets the needs of the Marine 


Corp’s TCO system in June 1993. 


3 See Chapter I for the list of alternatives. 
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While it is agreed that no system can currently satisfy all of the TCO 
requirements, the actual goal should be to pick the system that offers the "best" path 
toward achieving the Target TCO system requirements. The actual requirements for 
TCO were derived from the approved Mission Need Statement (MNS) dated 16 June 
1992 and are divided into core requirements and follow-on requirements. [Ref. 8] 


The following sections present the illustration. 


B. THE ILLUSTRATION 


1. Define Target System Functions and Capabilities 

The first step of the framework begins by defining the target TCO system 
functions and capabilities. The functions are those it must automate and the technological 
capabilities are those required to provide automated support to each of the functions. 
Values of each of the functions to the force are then estimated. The output of this step 
is a table highlighting the relationship between the target system’s technological 
capabilities and the functions it automates. 

The Target TCO System can be defined by using the core and follow-on 
requirements found in the MNS. From this document a list of functions requiring 
automation is derived. To obtain functions that are at the appropriate level of complexity 
for use in this framework, functional decompositions are required. The functions of the 
target system should be at a level that would allow the list of technological capabilities 
required to automate that function to be a list that is manageable in size. To illustrate 


this point, let us begin with the relatively high level function of producing an operations 
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order. This function could be decomposed into many lower level functions. For the 
purposes of this illustration only a subset of these lower level functions are used. Figure 
16 illustrates the simple functional decomposition required for this example. The 
functions chosen for this illustration are the mapping function, the overlay production 


function, and the information exchange function and can be seen in Figure 16. 


FUNCTIONAL DECOMPOSITION 


Produce an 
Operations Order 


Mapping Production Overlay Production Information 
Exchange 


Figure 16: Example of the Functional Decomposition Performed for Step 1 





Past, present, and future commanders and their staffs have performed, now 
perform, and probably will always perform these functions. The level of automated 
support will change as technologies mature. The requirement given in the MNS for TCO 
calls for these functions to be automated. The following table shows the relationship 
between these functions and their associated required technological capabilities. For the 
purpose of this illustration, the technological capabilities listed in the table are actually 
only a representative subset of the needed capabilities to provide automated support the 
these functions. The table in Figure 17 will serve as the definition of our TCO Target 


System functions and capabilities. 
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FUNCTION/CAPABILITY TABLE FOR THE TARGET TCO SYSTEM 


TECHNOLOGICAL FUNCTIONS 


Caoerine maioresteee 

——— 
[va Product Conpatbiny | x «dt SiC 
[ ScamnedWenCopabity | x ~—*+d| Sid 
[30 MepCopaoiny Sd Cd 


[DeseminateGrrays | Cd] SCX 
3-D Overlay eee A aa 

[large Cor PrintCapabiity [| | SX 

[large screenOwpey | CdS 

[taNcomectwty | Cd 

| Single Channel Radio Connectivity ora. | ee are x 

| Switched Backbone Connectivity | | | X | 


X -- Denotes that the Technological Capability is required to automate that Column ‘s Function 





Figure 17: Function/Capability Table for the TCO Target System 


Note that even some of the technological capabilities are quite complicated. 
Further definitions of the technological capabilities are needed in order to determine 
exactly when a particular system obtains that technological capability in the future. For 
example, the technological capability of DMA product compatibility requires that the 
system has the capability to build, store, retrieve, display, and transmit a digital map 
from either a raster or vector DMA map source. [Ref. 8] 

The next part of this step involves assigning values to the functions in the 
form of MOFEs or relative weights. As discussed in Chapter III, a method needs to 
devised for obtaining a value for each function. For the purpose of the illustration the 


elicitation method will be simulated by assigning an equal weight of one (1) to each 
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function. This serves to make further calculations simpler and is a viable option for the 
evaluators if time and resources limit the construction of a model or an exercise to derive 
MOFESs or the taking of a survey. Also, if the evaluators feel that relative weights won’t 
be acceptable to the decision makers, they have the opportunity to assign their own 
weights or assign equal weights to each function. 

Now that the Target System functions and capabilities are defined and a value 
of one (1) given to each of the functions, it is time to proceed to the next step of the 


framework. 


2. Define Candidate Paths 

The second step of the framework involves identifying all of the alternative 
base systems in terms of the technological capabilities they possess. All viable paths to 
the target system functions and capabilities that spawn from each alternative are then 
determined. The output of this step is an enumeration of all candidate paths. 

With only the draft final COEA report available at the time of this wmiting, 
the alternative systems listed in Chapter I may not be all that the USMC will consider. 
For purposes of this illustration, candidate paths will only be enumerated for two of the 
alternative systems, the Naval Tactical Control System-Afloat (NTCS-A) and the 
Intelligence Analysis System (IAS). These two systems will become the alternative base 
systems for TCO. 

Neither alternative obtains all of the technological capabilities required to 
automate the three target system functions, but each currently possesses a subset of them 


as shown in Figures 18 and 19. Figure 18 contains a function/capability table for the 
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FUNCTION/CAPABILITY TABLE FOR NTCS-A BASE SYSTEM 


TECHNOLOGICAL FUNCTIONS 
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X -- Denotes that the Technological! Capability is required to automate that Column s Function 


(x) Denotes that the System possesses this Technological Capability 





Figure 18: Function/Capability Table for the NTCS-A 


NTCS-A alternative base system and Figure 19 contains the function/capability table for 
the IAS alternative base system. The tables show what technological capabilities the two 
alternative base systems have today. 

The next step involves selecting the viable paths that spawn from each 
alternative that will eventually fulfill the target system’s requirements. In the case of 
NTCS-A, to provide the required automated support to the mapping function, scanned 
maps and three-dimensional maps technological capabilities are required. To meet the 
automation of overlays requirement, a three-dimensional overlay capability is required 


and to automate the information exchange function, LAN connectivity and Switched 


vA 


FUNCTION/ICAPABILITY TABLE FOR IAS BASE SYSTEM 


TECHNOLOGICAL FUNCTIONS 
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(x) Denotes that the System possesses this Technological Capability 





Figure 19: Function/Capability Table for the Intelligence Analysis System 


Backbone connectivity is required. Similarly, in the case of IAS, to provide the required 
automated support to the mapping function, scanned maps and three-dimensional maps 
technological capabilities are required. To meet the automation of overlays requirement, 
a three-dimensional overlay capability and large screen display capability is required and 
to automate the information exchange function, LAN connectivity and Switched 
Backbone connectivity is required. 

Through cooperation of technical, operational, and programmatic experts, 
viable timed patterns of adding these capabilities can be developed. The table in Figure 


20 summarizes the viable paths that are used in this illustration. Only two paths for each 
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THE VIABLE PATHS 


TECHNOLOGICAL ALTERNATIVE BASE SYSTEMS 


Scanned Map [Scannediap Capabiity =a 2 vee 1 VER 2 


NOTE: Contents of table denotes what year a particular path will obtain that Technological Capability 





Figure 20: The Viable Paths 


alternative base system has been chosen for simplicity, although there may actually be 
many viable paths. The four paths will become the Candidate Paths for the evaluation. 
The table in Figure 20 indicates for each alternative base system’s path, what year a 
particular technological capability will be added to the base system. As discussed in 
Chapter III, selection of these candidate paths require experts in many disciplines to 
agree on what can be considered viable upgrade paths. One method would be to charter 
an independent agency to perform this task. With the candidate paths determined, the 
evaluator can move on to the next step of getting the discounted values and costs of each 


candidate path. 


3. Get Values and Costs 
The third step of the framework involves assigning functionally derived 
values and capability derived costs to each candidate path at discrete time intervals. 


These values and costs are then discounted to present values and costs and added 


i) 


together. The output of this step is a single discounted value and a single discounted cost 
associated with each candidate path. 

Figure 21 graphically illustrates what each candidate path looks like. For 
simplicity, only a time span of five years is chosen. It is clear that each candidate path 


is simply a timed insertion of technological capabilities. 


THE CANDIDATE PATHS 


PLANNING 
HORIZON 


TARGET 
SYSTEM 


ALTERNATIVE INCREMENTAL UPGRADE PATHS TOWARD THE TARGET 
BASE SYSTEMS 


A - Scanned Map Capability 

B - 3-D Map Capability 

C - 3-D Overlay Capability 

D - Large Screen Display 

E - LAN Connectivity 

F - Switched Backbone Connectivity 


LEGEND FOR THE 
TECHNOLOGICAL CAPABILITIES 
THAT ARE ADDED 





Figure 21: The Viable Candidate Paths 


As technological capabilities are added, the system will periodically obtain enough 
technological capabilities to provide the required level of automated support to one or 


more of the target system functions. Each candidate path will eventually succeed in 
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reaching the required level of automation stated in the definition of the target system 
functions and capabilities. 

The overall discounted value of a candidate path is the sum of the discounted 
values of each function. The discounted value of a function depends on when (e.g., what 
year) that function is successfully automated in a candidate path. A simple method for 
discounting the value of a function is illustrated in Figure 22. The graph shows the 
relationship between the value of a function and the year in which it is added to the 
candidate path. If the system obtains a function today, it receives the full value of that 
function (one). Likewise, if the function is not automated until say 10 years from now, 
it only receives half’ the determined value of the function (one-half). How the graph 
behaves in between the present and the planning horizon depends on the time utility or 
temporal importance the users place on receiving a particular function”. Functions that 
are added sooner will contribute more value to the overall value of a candidate path than 
if they were added later. 

To compute the discounted value of the functions, the linear relationship in 
Figure 22 is used for simplicity. This yields the following equation for determining the 


discounted value of a function: 


* The residual value of one-half was arbitrarily chosen by the authors. Evaluators should 
feel free to pick an appropriate residual or terminal value of obtaining a particular function. 


> A thorough discussion on Utility theory can be found on page 258 of Reference 29. 


e 


DV,=1-t(5) (5) 


Where DV, is the discounted value of the i” function, 1 is the value of each 
function at t = 0, and t is the year or time period that the candidate path successfully 


automates the function 1. 
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Figure 22: How the Value of Functions are Discounted to the Present 
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To find the overall discounted value of the candidate path, the individual 
discounted values of each function are simply added. The following equation will be 


used: 


N 
ODV=)> DV, (6) 


T=1 

Where ODV is the overall discounted value of the candidate path, i is a 
counter for the individual functions, N is the total number of functions, and DV, is the 
discounted value of the i® function. 

Costs of the candidate paths that the framework uses are the cost of the 
alternate base system if bought today and the cost of adding a particular technological 
capability to given base system. Costs of adding a particular technological capability 
may be different for each alternative base system because each system may require 
different combinations of hardware and/or software to provide the required level of 
automation depending on the current configuration of a given base system. Figure 23 
shows the estimated costs of adding the needed technological capabilities to the two 
alternative base systems chosen. 

Discounted costs of adding technological capabilities are computed using the 


standard discounting function: 
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COST OF PROVIDING ADDITIONAL TECHNOLOGICAL CAPABILITIES 


TECHNOLOGICAL ALTERNATIVE BASE SYSTEMS 


Scanned Map =< $ —————sa0n000OCO 000 $ [$400,000 000 
-3-D Map Capability $ 207,000 $ 207,000 


NOTE: Contents of table denotes cost of adding the Technological Capability to a particular Base System. 
Costs were estimated using data from the COEA Final Report {Draft}, Appendix K (Costs) 





Figure 23: Technological Capabilities and their Costs 


> aah 4 


Where DC; is the discounted cost of adding the j* technological capability, 
r is the discounting factor or interest rate, y is the year or time period, and C;, is the cost 
of adding the j” technological capability to the system. 

To calculate the overall discounted cost of the candidate path, the initial cost 
of the alternative base system is added to the discounted cost of each technological 
capability that is added to the candidate path. The following equation is used to compute 
the overall discounted cost of a candidate path: 

M 
ODG= 16a) De (8) 
5=0 

Where ODC is the overall discounted cost of a candidate path, IC, is the 


initial cost of buying the alternative base system, M is the total number of technological 
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capabilities that are added to a candidate path, and DC; is the discounted cost of adding 
the j" technological capability. 
Figure 24 illustrates how the above calculations are used to calculate the 


overall discounted value and cost of the first candidate path. 


VALUE AND COST OF A CANDIDATE PATH 


FUNCTIONS AUTOMATED None None Mapping Overlays None Info Exch 


VALUE 0 0 1 4 0 4 
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~ DISCOUNTED 


VALUE 0 


0 0 
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OVERALL DISCOUNTED VALUE OF THE CANDIDATE PATH=0.9+ 0.85 +0.75=25 


OVERALL DISCOUNTED COST OF THE CANDIDATE PATH = 1500 + 363.6 + 171+ 155.5 + 68.3 + 293.7 





Figure 24: Computation of the Discounted Value and Cost of a Candidate Path 


The procedure for finding the overall discounted value and cost of a candidate 
path is simple. The first step involves determining when (or at which time periods) the 
candidate path will succeed in automating the functions of the target system. As can be 


seen in Figure 24, the first candidate path succeeds in providing the required automated 


a2 


support to the mapping function in year two. The overlay function is obtained in year 
three and the information exchange function is obtained in year five. The second step 
requires the use of Equation (1) to compute the discounted value of each of the functions. 
The third step uses Equation (3) to calculate the discounted costs of the technological 
capabilities that are added to the system. The fourth and fifth steps use Equations (2) 
and (4) to compute the overall discounted value and cost of the candidate path. As can 
be seen from Figure 24, calculations for the first candidate path yield a discounted value 
of 2.5 and discounted cost of 2552.1K. Figure 25 shows the results of doing these 
calculations on the remaining candidate paths. 

The next step of the framework discusses the selection of a candidate path 


using the values and costs that were calculated in this step. 


DISCOUNTED VALUES AND COSTS OF THE CANDIDATE PATHS 


ALTERNATIVE BASE SYSTEMS 


PATH 1 PATH 2 PATH 3 


rm ne 
DISCOUNTED COST 2992.1K 2498K 2948K 


Figure 25: The Discounted Value and Cost of Each Candidate Path 
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4. Select 
The last step of the framework involves selecting the best candidate path. In 
this kind of decision, the "best" candidate path is the one that maximizes value subject 


to cost, resource, and risk constraints”. The rule or problem is stated as: 


Maximize: Value 
Subject to: ® Cost 
@ Resource 
@® Risk 


An easy procedure for selecting the best candidate path given the data like 
that in Figure 25, is to first remove the candidate paths that don’t satisfy at least one of 
the constraints from consideration. For the purpose of the illustration, say a budget of 
2500K has been allocated for the C* system and that all candidates meet the resource and 
risk constraint. From Figure 25, candidate paths one and three exceed the established 
cost constraint, so they will not be considered. The next step is to select from the 
remaining candidate paths, the one that has the greatest value. For the illustration, 


candidate path four is selected”. 


2° While this framework does not expand on the resource and risk constraint, they are still 
important issues that deserve a fair amount of attention for an actual evaluation. 


*7 Candidate path four had the greatest value because it succeeded in automating some of 
the functions sooner than the other paths. It also had the least cost because the more expensive 
technological capabilities were added later in its path, which allowed them to take advantage of 
the discounting. 
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C. CONCLUSIONS 

The illustration is intended only to give the reader a general idea of how to apply 
the concepts and procedures of this framework. For that purpose, the illustration is an 
extremely simplified one. Evaluations of actual systems would begin with a much bigger 
function/capability table for the definition of the target system functions and capabilities 
and would require more data. Nonetheless, the steps of the framework are fairly simple 
to follow and flow logically from one step to the next. The tables and data produced by 
this framework provide the decision makers with invaluable insight into how the various 
alternatives will change over time and may highlight evolutionary issues that have been 
overlooked in the past. This framework will result in decisions that have taken into 


account the difficult, but ever present, temporal component of evolving C* systems. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 


1. The C? Systems Procurement Environment 

Chapter II presented a discussion of the technology initiatives that will impact 
C* systems. The Evolutionary Acquisition concept was introduced and topics such as 
Non-Developmental-Items, Commercial-Off-the-Shelf products, and open architecture 
standards were presented. It is important that the procurement environment in which C 
systems are procured be understood by the evaluators. Important factors of the 
procurement environment that effect C* systems include; the recent increased rate of 
technological change, the mandated use of the Evolutionary Acquisition concept, the use 


of NDI and COTS products, and the evolving open architecture standards. 


2. eur reat Frameworks 
Chapter II also presented a cross-section of some of the current C* system 
evaluation frameworks. The Mission-Oriented Approach, the Modular Command and 
Control Evaluation Structure, and the COEA team’s evaluation approach were discussed 
and their applicability to current C* systems evaluation highlighted. None of these 
frameworks or MeMOdCIoetes specifically deal with the temporal component of C 


systems. 
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3. The New Framework 
Chapter III presented a new framework that focuses the evaluation of 
alternatives on their evolutionary upgrade paths. The framework presents a method that 
could be useful to decision makers in choosing between alternative C’ systems. The 


framework contains four steps: 


1. Define target system functions and capabilities. 


2. Define all viable upgrade paths from each alternative base system to the target 
system; each path becomes a candidate path. 


3. Develop discounted value and discounted cost for each candidate path. 


4. Select the candidate path that maximizes value subject to stated cost, resource, 
and risk constraints. 


Methods and procedures for accomplishing each step was presented. 
4. The Illustration 
hapten IV provided an illustration of the framework. The illustration 
focused on the Marine Corp’s TCO system described in Chapter I. The illustration 


clarified how the methods of the framework can be applied. 


B. CONCLUSIONS 


1. The C* Systems Procurement Environment 
The following conclusions can be made in regard to the environment in which 


C’ systems are procured: 
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1. That C*® systems must capitalize on emerging technologies to remain mission 
capable. 


2. That C® systems will incorporate evolutionary upgrades throughout their useful 
life cycle if procured through evolutionary acquisition. 


3. That most of these evolutionary upgrades will be composed of NDI or COTS 
products that adhere to “open system" standards. 


4. That current evaluation frameworks do not base their evaluations on the 
temporal component of C’ systems. 


2. The Framework as an Effective Tool for Evaluation 

The new framework presented here offers an alternative approach to C’ 
systems evaluations. The framework’s methods for dealing with upgrade paths can be 
widely applied to many systems. C* systems of today and in the future will constantly 
change to keep up with state-of-the-art technologies. This aspect, called the temporal 
component, is directly addressed by this framework. 

This framework can be a very useful tool for evaluating C*’ systems or 
subsystems that will undergo many evolutionary upgrade changes throughout their useful 
life cycle. The author concludes that evaluations of alternatives can be based on 


cost/benefit analysis performed on the perceived future upgrade paths of the alternatives. 


3. The TCO Problem 
The TCO program will no doubt go through many changes during its life 
cycle. The concept is a valid one and it is greatly needed to support the warfighters in 


today’s environment. 
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It is almost certain that some new baseline system will be bought to fulfill the 
TCO requirements. The next upgrade to TCO will become a new baseline system. This 
baseline system will form the core on which evolutionary upgrades will be incrementally 
added during its useful life cycle. Several different acquisition strategies are currently 
being considered by the project office, but one thing is certain about the program, many 
periodic upgrades will be integrated into the system. At each decision point, choices will 
have to be made as to which upgraded product to buy. This framework could be used 


at these subsequent decision points to help the USMC pick the "best" product. 


C. RECOMMENDATIONS 
This framework represents an initial effort at basing the evaluation of alternatives 
on their future evolutionary upgrade paths. General concepts and procedures were 
introduced. Areas that could benefit greatly by further research include: 
iT More streamlined methods for determining target system functions and 
capabilities. 


2. Methods that more accurately predict future upgrade technological capabilities 
and costs. 


3. Procedures that would expand the framework to include evaluations of the 
uncertainty and risk issues. 
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ACE 
ACMC 
ADM 
ADPE-FMF 
AE 
AFATDS 
AHP 
AIC 
AOA 
APO 
ARC 
ASD 
ASP 
ASPO 
ATACCS 
ATCCS 
ATDL-1 
ATO 
AUTODIN 
C2 

C’MP 

C3 

Cl 

Cl 


APPENDIX A: GLOSSARY 


Aviation Combat Element 

Assistant Commandant of the Marine Corps 
Acquisition Decision Memorandum 

Automatic Data Processing Equipment-Fleet Marine Force 
Acquisition Executive 

Advanced Field Artillery Tactical Data System 
Analytical Hierarchy Process 

Automated Information Center 

Amphibious Operational Area 

Acquisition Project Officer 

Atlantic Research Corporation 

Assistant Secretary of Defense 

Acquisition Strategy Plan 

Acquisition Sponsor Project Officer 

Army Tactical Automated Command and Control System 
Army Tactical Command and Control System 

Army Tactical Data Link-1 

Air Tasking Order 

Automatic Digital Network 

Command and Control 

Gémmand and Control Master Plan 

Command, Control, and Communications 

Command, Control, Communications, and Intelligence 


Command, Control, Communications, Computers, and Intelligence 
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Gir 


CATF 
CE 
CECOM 
CEO 
CG 
CIM 
CIP 
CMC 
COC 
COEA 
COTS 
CP 
CSI 
CSSE 
Gils 
DCA 
DISA 
DMA 
DoD 
DOS 
DPM 
EA 
EPLRS 
FIPS 
FMF 
GCE 
GOR 


Command, Control, Communications, Computers, 
Intelligence, and Interoperability 

Commander Amphibious Task Force 

Command Element 

U.S. Army Communications-Electronics Command 
Chief Executive Officer 

Commanding General 

Corporate Information Management 

Combat Information Processor 

Commandant of the Marine Corps 

Combat Operations Center 

Cost and Operational Effectiveness Analysis 
Commercial-Off-The-Shelf 

Command Post 

Command Systems Incorporated 

Combat Service Support Element 

Command Tactical Information System 

Defense Communications Agency 

Defense Information Systems Agency 

Defense Mapping Agency 

Department of Defense 

Disk Operating System 

Deputy Program Manager 

Evolutionary Acquisition 

Enhanced Position Location and Reporting System 
Federal Information Processing Standard 

Fleet Marine Force 

Ground Combat Element 


General Operational Requirement 
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GOSIP 
GUI 
HQMC 
IAS 

IEC 

ISO 
JTIDS 
LAN 
MAGTF 


MARCORS YSCOM 


MCASS 
MCCDC 
MCES 
MCHS 
MCOTEA 
MCS 
MCTSSA 
MOA 
MOE 
MOFE 
MOP 
MORS 
MEF 
MEU 
MIFASS 
MNS 
MTACCS 
NDI 
NMSD 


Government Open System Interconnection Profile 
Graphical User Interface 

Headquarters Marine Corps 

Intelligence Analysis System 

International Electrotechnical Committee 
International Standards Organization 

Joint Tactical Information Dissemination System 
Local Area Network 

Marine Air Ground Task Force 

Marine Corps Systems Command 

MTACCS Common Application Support Software 
Marine Corps Combat Development Command 
Modular Command and Control Evaluation Structure 
MTACCS Common Hardware Support 

Marine Corps Operational Test and Evaluation Activity 
Maneuver Control System 

Marine Corps Tactical Systems Support Activity 
Mission Oriented Approach 

Measure of Effectiveness 

Measure of Force Effectiveness 

Measure of Performance 

Military Operations Research Society 

Marine Expeditionary Force 

Marine Expeditionary Unit 

Marine Integrated Fire and Air Support System 
Mission Need Statement 

Marine Corps Tactical Automated Command and Control System 
Non-Developmental-Item 


National Military Strategy Document 
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NTCS-A 
O&S 
OMB 
PM 
POSIX 
R&D 
RDT&E 
SMART 
SOCEX 
TCIM 
TCO 
TNS 

US 
USMTF 
USPACOM 
WAN 


Naval Tactical Command System - Afloat 
Operations and Support 

Office of Management and Budget 

Program Manager 

Portable Operating System Interface - UNIX 
Research and Development 

Research Development Testing & Evaluation 
Simple Multi-Attribute Rating Technique 
Special Operations Command Exercise 
Tactical Communications Interface Module 
Tactical Combat Operations system 

Tactical Network Server 

United States 

United States Message Text Formats 

U.S. Pacific Command 


Wide Area Network 
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